6. Проказник и Система управления версиями

Git — распределённая система управления версиями. На сленге переводиться как "Проказник". Система разработана Линусом Торвальдсом, для облегчения разработки ядра операционной системы Linux (Kernel). Git помогает разработчикам управлять кодом, отслеживать изменения, работать в команде и защищать проект от ошибок и сбоев. Вот основные преимущества и смысл использования в разработке:

Контроль версий

Git позволяет отслеживать изменения в коде проекта с течением времени. Каждый раз, когда в проект вносятся изменения, они могут быть зафиксированы в виде "коммита" (снимка). Это создает "историю" проекта, где каждый коммит хранит информацию о том, что было изменено, кто это сделал и когда.

Преимущества:

  • Возможность откатиться к предыдущим версиям проекта, если новые изменения оказались некорректными.
  • Исторический обзор всех изменений, что помогает понять, как проект эволюционировал.

Параллельная разработка с ветвлением (branches)

Git поддерживает создание веток (branches), которые позволяют разработчикам работать над разными частями проекта одновременно, не мешая друг другу. Ветки обычно создаются для новых функций, исправления ошибок или экспериментов, а затем могут быть объединены в основную ветку проекта.

Преимущества:

  • Возможность работать над новыми функциями или исправлениями без риска нарушить основной код.
  • Объединение веток позволяет объединять работу нескольких разработчиков и разрешать конфликты, если изменения затрагивают одни и те же файлы.

Совместная работа

Git делает процесс совместной работы над проектом более организованным и безопасным. Каждый разработчик может клонировать репозиторий проекта на свою локальную машину, работать над ним и вносить свои изменения, а затем отправлять их обратно в удаленный репозиторий.

Преимущества:

  • Возможность разработчикам в разных частях мира работать над одним и тем же проектом, синхронизируя свои изменения через удаленный репозиторий (например, GitHub, GitLab, Bitbucket).
  • Прозрачность изменений: каждый разработчик видит, кто и какие изменения вносил, что упрощает контроль и организацию работы.

Обнаружение и устранение ошибок

С Git легче найти и исправить ошибки. Если что-то пошло не так, можно вернуться к предыдущему коммиту, где код работал корректно. История изменений также помогает понять, какие изменения привели к появлению ошибки.

Преимущества:

  • Быстрый откат: если новая функция сломала что-то, можно быстро вернуться к стабильной версии.
  • Поиск виновных изменений: благодаря истории коммитов можно точно выяснить, кто, когда и в каком месте изменил код, вызвавший проблему.

Резервное копирование и безопасность

Git создает резервные копии проекта. Код хранится как на локальной машине разработчика, так и в удаленном репозитории, что защищает проект от потери данных в случае сбоя на локальной машине.

Преимущества:

  • Безопасное хранение кода: код не будет потерян даже в случае проблем с оборудованием.
  • Восстановление изменений: если какая-то версия кода была удалена, её можно восстановить из истории коммитов.

Код-ревью и контроль качества

Git поддерживает процессы код-ревью, когда изменения, предложенные разработчиком, проверяются его коллегами перед включением в основную ветку. Это помогает улучшить качество кода, поскольку ошибки или неоптимальные решения могут быть замечены до слияния.

Преимущества:

  • Повышение качества кода за счет совместной проверки изменений.
  • Возможность обучаться у коллег через обсуждение и анализ предлагаемых решений.

Скорость и эффективность

Git спроектирован так, чтобы быть очень быстрым и эффективным, даже при работе с большими проектами. Вся работа (например, фиксация изменений, создание веток) выполняется локально на машине разработчика, и только обмен данными с удаленным репозиторием требует интернета.

Преимущества:

  • Локальная работа: большинство операций выполняются локально, что делает процесс разработки быстрым.
  • Эффективное слияние изменений: Git эффективно обрабатывает конфликты и помогает объединять изменения из разных веток.

Поддержка DevOps процессов

Git отлично интегрируется в CI/CD (Continuous Integration/Continuous Deployment) процессы, которые автоматизируют тестирование и развертывание кода. Например, при каждом новом коммите в основную ветку можно автоматически запускать тесты и деплоить новую версию приложения.

Изображение - Объединение веток в Github Actions

Преимущества:

  • Автоматизация разработки: новые версии кода могут автоматически тестироваться и деплоиться.
  • Быстрое внедрение изменений: можно сразу увидеть результаты внесённых изменений в тестовой или даже продакшн-среде.

Задание

Создайте репозиторий на сетевом или локальном диске и сохраните предыдущую работу в репозиторий. Из-за малого объема сетевых дисков желательно создавать новый репозиторий на каждую практическую работу

  1. Создать репозиторий используя исключительно латинские символы (Только на английском)
    • Запустите приложение Git GUI установленное на ПЭВМ и нажмите Create New Repository, после выберите директорию, где будет находится репозиторий (Рекомендуем создать новую директорию под репозиторий)
  2. Попробуйте добавить новые элементы в директорию и нажмите Rescan для получения изменений.
  3. После Rescan у вас появиться новые файлы во вкладке Unstaged Changes. Теперь вы сможете их подготовить к сохранению, через нажатие Ctrl+T, после чего они перейдут во вкладку Staged Changes, выделив один из них вы можете его убрать из списка обратно в Unstaged Changes путём нажатия Ctrl+U
  4. После перейдите в Initial Commit Message и введите описание изменений и затем нажмите Commit. После этого откройте вкладку Repository и там Visualize All branch History

Словарь

Основные термины:

  1. Репозиторий (Repository) — это место, где хранится весь проект, включая все его файлы, папки и историю изменений. Репозиторий может быть локальным (на вашем компьютере) или удалённым (например, на GitHub).
  2. Коммит (Commit) — это зафиксированное изменение в репозитории. Каждый коммит содержит уникальный идентификатор (хеш), сообщение о том, что было изменено, и метаданные (кто и когда сделал коммит).
  3. Ветка (Branch) — это независимая линия разработки. Ветки позволяют работать над различными функциями или исправлениями одновременно. Основная ветка часто называется main или master.
  4. Слияние (Merge) — это процесс объединения изменений из одной ветки в другую. Это часто используется для добавления новых функций в основную ветку.
  5. Отслеживаемые файлы (Tracked files) — это файлы, которые уже добавлены в репозиторий и отслеживаются Git. Изменения в них будут учитываться при коммите.
  6. Неотслеживаемые файлы (Untracked files) — это файлы, которые находятся в рабочей директории, но ещё не добавлены в репозиторий с помощью git add.
  7. Стадия индексации (Staging area) — это область, где собираются изменения перед коммитом. Добавленные файлы сначала попадают в staging area, после чего они могут быть зафиксированы в коммите.
  8. Pull — команда, которая объединяет команду fetch (загрузка изменений с удалённого репозитория) и merge (слияние изменений с локальной веткой). Она обновляет локальную копию репозитория, подтягивая изменения с удалённого сервера.
  9. Push — отправка ваших локальных коммитов на удалённый репозиторий, чтобы другие разработчики могли получить доступ к вашим изменениям.
  10. Pull Request (PR) — это запрос на слияние изменений из одной ветки в другую, обычно используется в системах управления кодом, таких как GitHub или GitLab. Позволяет предложить изменения для ревью и слияния в основную ветку проекта.
  11. Клон (Clone) — это копия удалённого репозитория, которую вы можете скачать на свой локальный компьютер для работы.
  12. Форк (Fork) — создание копии чужого репозитория в вашей учётной записи, чтобы можно было вносить изменения, не затрагивая оригинальный проект. Это обычно используется для работы с открытым исходным кодом.
  13. Конфликт (Conflict) — возникает, когда Git не может автоматически объединить изменения в двух ветках, например, если один и тот же участок кода был изменён по-разному. Конфликт нужно разрешить вручную.
  14. Rebase — это команда для перемещения или "перепроигрывания" одной ветки поверх другой. Она помогает поддерживать более чистую историю коммитов без лишних слияний.